Once #479 is ready, we can replace this with a ForeignKey to either CatalogCourse or CourseRun (depending on the outcome of the discussion about courses vs runs.

Could we just use django-simple-history like many other parts of the platform do? Or do we really need to track these state transitions carefully?

from simple_history.models import HistoricalRecords

...
    # Keep track of the history of this table:
    history = HistoricalRecords()

@bradenmacdonald, when we auto-enroll a learner after they create an account, we want to update the existing audit record with the enrollment, which ensures record consistency. It also allows checking bulk enrollments directly in Django admin and providing a readable history with a simple inline for each enrollment.

OK. In that case, I'm wondering if we'll want to find a way to have some common code/models/tables for managing enrollments, as it seems like the *Enrollment, *EnrollmentAllowed, *EnrollmentAudit, models and logic may be very similar for both courses and pathways, and perhaps other things in the future. Doesn't have to happen now though, as it's probably more trouble than it's worth.

@bradenmacdonald, we ported some logic from openedx-platform, so it should be possible to introduce a reusable approach at some point, but moving course enrollments away from openedx-platform (even partially) would be a significant task, as there are some edge cases to consider/deprecate (like processing the refunds for the verified enrollment track, which is also tied to the certificates API).

It may make sense for Pathway and PathwayStep to be part of openedx_content, but I think enrollment-related models definitely belong somewhere else.

It might make sense to put Pathway and Pathway step into the new openedx_catalog app (#479), and enrollment into a new app (openedx_learning?)

@bradenmacdonald, should we create openedx_learning as a sibling to openedx_content or extract this to a separate repository? This is another case that would require access to the opendx-platform API, because it handles enrolling users in courses. In the Learning Paths plugin, we do this way.

We'll have to discuss this as I'm not sure. Putting it in a completely separate repo is an easy way to solve the problem of "openedx-core shouldn't import from platform"

@bradenmacdonald, we could do the following:

1. Keep pathway models as-is.
2. Move enrollment models to openedx_learning.
3. Add models for pathway and step criteria, with CEL support (I have a local draft for this that I wrap up and push next week).
4. Add APIs for these models.
5. Fork the learning-paths-plugin repo into openedx-pathways and remove everything other than Open edX interactions (via the compat layer), REST APIs, and the user post_save signal receiver there. This repo would interact with openedx-core via the new Python APIs, and would not use the models directly.
6. Add progress calculations to openedx-pathways.

opendx-platform may not need to use anything from openedx-core for the pathways; it would only install openedx-pathways, which would provide all the logic to the MFEs via REST APIs.

Please let me know if you have a different architecture in mind for openedx-core. Once we add APIs for grading and enrollments, we could move things from openedx-pathways to openedx_learning. However, what can we do right now to move this one forward?

@Agrendalath That seems reasonable to me! But I'd really like input from @ormsbee and @kdmccormick .